1. Field of the Invention
The present invention relates to Digital Rights Management, and more specifically to a method for importing Digital Rights Management data to convert non-Open Mobile Alliance Digital Rights Management data into Open Mobile Alliance Digital Rights Management data for a user domain.
2. Discussion of the Background
With the increase of devices capable of delivering multimedia content to a user, a user may own, operate, or maintain control or responsibility over several devices, such as a networked home media center entertainment system and handheld devices with varying degrees of network connectivity. The handheld devices may include a mobile phone and a portable music player. The network connectivity may include, for example, wireless connectivity through a mobile phone or a wired broadband internet connection through a personal computer. The user may purchase and download content, such as multimedia content, or programs for operation on one device over the network connection.
However, the user may also wish to operate the content or programs on other devices owned by the user. Therefore, according to the Open Mobile Alliance (OMA) Digital Rights Management (DRM) Secure Content Exchange (SCE) Requirements (hereinafter, referred to as “OMA SCE Requirements”), suggested by OMA Mobile application software standardization organization, which is incorporated herein by reference, and which established the concept of a “user domain,” the user may establish a user domain. A user domain may include other devices owned, operated, controlled, or under the responsibility of the user. The user may add devices to the user domain, and may use a device in the user domain to obtain content useable in the user domain. Further, the user may share content between devices in the user domain via network connectivity or via storage memory suitable for transferring content between devices, such as Secure Removable Media (SRM). Alternatively, such as where content is streamed over a network connection, the user may share authorization to stream the content with other devices in the user domain. This may be achieved by sharing, for example, user tokens associated with the authorization.
Thus, user domain refers to the group of devices that may share DRM content. A device may include any device that may share DRM content within the user domain. User domain management may include such management tasks as adding devices to and removing devices from the user domain, and application of domain policy.
Thus, a content provider may allow replication and use of content among devices in the user's user domain. Further, the content provider may limit and/or prohibit distribution and use of such content to devices outside the user domain.
A user domain may be created by a user through the operation of one device in the user domain with network connectivity. For example, a user may create a user domain by operating a device to view a list of possible domain policies. Various domain policies may be developed, and one of which may be selected by a user as most appropriate for that user. An SCE enabler may support only a single domain policy for a user domain. Domain policies for user domains, issued by a Domain Authority (DA), may include such constraints as the maximum number of devices in the user domain, temporal restrictions on the use of content, or frequency of the use of content.
The DA may provide the selected domain policy and a Domain Key (DK) to a Domain Enforcement Agent (DEA) stored in the user's device. The device, through the DEA, may create and manage the user's user domain.
The user may then add other devices to the user domain. For example, a user may connect a mobile phone, portable music player, and a Home Media Center to the device and add these devices to the user domain. The domain policy issued by the DA may limit the number of devices that may be added to the user domain, and the DEA may prevent the number of devices added to the user domain from exceeding this limit.
When a user acquires content with a user domain Rights Object (RO), the user may wish to share the content with the devices in the user domain or with devices outside the user domain. The user may then connect the connected device to other devices in the user domain to transfer copies of the content and its corresponding RO to other devices in the user domain.
An SCE enabler may enable a rights issuer (RI), which may exchange a Content Encryption Key (CEK) with a content issuer, to specify usage permissions for consumption of rights on and transfer of rights between devices that are in the user domain. Usage permissions may include permissions to play, copy, and/or move content among devices in the user domain. An SCE enabler may also enable an RI to specify usage permissions for rights among devices outside the user domain. Usage permissions may include permissions to copy and move content to devices outside the user domain. Alternately, usage permissions may prohibit devices in the user domain from copying or moving content to devices outside the user domain.
Thus, the OMA SCE Requirements introduced the concept of “user domain” so that a user can directly perform user domain management instead of performing user domain management through an RI. Therefore, OMA SCE Requirements also introduced the concept of DA and DEA so that defining and describing a domain policy can be performed by the DA and enforcement of the domain policy can be performed by the DEA. The DA and DEA may be separate entities or may be integrated into a single entity.
A DA may define and describe the domain policy and may deliver such domain policy to the DEA. The DEA may receive the domain policy from the DA, and may define and manage the user domain based on the received domain policy. That is, the user domain generated by the DEA is also managed by the DEA. If the DA and DEA are integrated as a single entity, the DA may define the user domain and may perform domain management without interfacing with a separate DEA.
FIG. 1 illustrates a schematic diagram of the OMA SCE Requirements.
Unlike the traditional OMA DRM V2.0 standard (hereinafter, referred to as “OMA DRM V2.0”), which is also incorporated by reference and which antedates the OMA SCE Requirements, the OMA SCE Requirements include:
(1) Import function by a Local Rights Manager (LRM);
(2) User Domain function by the DA and the DEA; and
(3) Move function to move RO from one device to another device.
Hereinafter, the Import function and User Domain function will be described in more detail.
OMA SCE Requirements provide an Import function that may be performed by the LRM. Import function refers to converting non-OMA DRM data into OMA DRM data.
For example, a device compatible with OMA DRM may attempt to play non-OMA DRM data. In this case, the non-OMA DRM data should be converted or imported into OMA DRM data by an LRM according to OMA SCE Requirements. Thus, the LRM imports the non-OMA DRM data into DRM Content Format (DCF) and imports an RO for the OMA DRM, which are called “Imported DCF” and “Imported RO,” respectively. Imported DCF and Imported RO, which support OMA DRM, can be used by a DRM agent in a device compatible with OMA DRM according to OMA SCE Requirements.
As described above, user domain permits a user to perform user domain management for a number of devices included in the user domain instead of performing user domain management for each device through a rights issuer (RI), as was established in the traditional OMA DRM V2.0 standard.
Other features of the traditional OMA DRM V2.0 standard are compatible with OMA SCE Requirements, however. For example, OMA DRM V2.0 includes a 4-pass registration protocol and 2-pass rights object (RO) acquisition protocol for a device to acquire an RO.
FIG. 2 illustrates a 4-pass registration protocol according to OMA DRM V2.0.
The 4-pass registration protocol permits the device and the RI to exchange and register information to each other. If the protocol is successful, the device can possess RI context, which contains information about the RI, and the RI can possess information about the device.
According to the 4-pass registration protocol, the device first transfers a Device Hello message including device information to the RI. The Device Hello message may contain protocol version, device ID, and supported cipher algorithms for the device.
The RI transfers an RI Hello message including RI information to the device in the second stage. The RI Hello message contains transfer result, session ID, protocol version, RI ID, supported algorithm, and other verification and server information.
The device then transfers a RegistrationRequest message to the RI to register the device with the RI in the third stage. The RegistrationRequest message contains verification data, such as session ID, message transfer time, certificate and signature, and nonce.
The RI finally transfers a RegistrationResponse message to the device in the fourth stage. This RegistrationResponse message contains verification data, such as device registration result, session ID, RI certificate/digital signature, and Online Certificate Status Protocol (OCSP) Response, which may be sent to the RI in response to an OCSP Request message that may be sent from the RI to an OCSP Responder upon certain contingencies that will not be described in further detail.
FIG. 3 illustrates a 2-pass RO acquisition protocol according to OMA DRM V2.0.
The 2-pass RO acquisition protocol is performed to acquire RO following the 4-pass registration protocol. On the basis of RI context resulting from performing the 4-pass registration protocol, the device receives RO from the RI by sending a RORequest message to the RI, and by receiving the ROResponse message from the RI. Additionally, an OCSP Response may be sent to the RI in response to an OCSP Request message sent from the RI to an OCSP Responder upon certain contingencies.
Additionally, the device may be registered with a corresponding user domain. FIG. 4 illustrates a 2-pass join domain protocol according to OMA DRM V2.0.
The 2-pass join domain protocol is used by a device supporting OMA DRM V2.0 to use domain-based RO. In this case, the device can use the domain-based RO after joining a corresponding domain using the 2-pass join domain protocol. The 2-pass join domain protocol is generally operated only after the 4-pass registration protocol occurs. Once joined, the device can use the RO through the process shown in FIG. 5.
FIG. 5 illustrates a method for using RO by a device according to OMA DRM V2.0.
At the first stage, devices D1, D2, and D3 join a domain using the 4-pass registration protocol as shown FIG. 2 and the 2-pass join domain protocol as shown in FIG. 4. At the second stage, the device D1 acquires the RO from the RI through the 2-pass RO acquisition protocol as shown in FIG. 3. At the third stage, the acquired RO is transferred from device D1 to the devices D2 and D3. Since the devices D2 and D3 joined the same domain as the device D1, the devices D2 and D3 can use the RO received from the device D1. At the fourth stage, the device D1 transfers the RO to the device D4, which has not joined the same domain as device D1. Since the device D4 has not joined the domain, the device D4 joins the domain through the 2-pass join domain protocol at the fifth stage and uses the RO received from the device D1.
However, the OMA SCE Requirements do not describe a method for importing and changing non-OMA DRM data to OMA DRM data by LRM, or a method which allows the DRM agent belonging to the user domain to use the imported OMA DRM data.